IAMのベストプラクティス！rootユーザのアクセスキーはできるだけ削除していきましょう

みなさん！rootユーザのアクセスキー、使ってませんか？

AWSのユーザのアクセスキー/シークレットキー(以下、アクセスキー)が漏洩すると、その所持する権限に応じて様々な被害が生じます。

参考： 【実録】アクセスキー流出、攻撃者のとった行動とその対策 | Developers.IO

中でもrootユーザは何でもできる最強の権限を持つため
万一そのアクセスキーが悪意ある者の手に渡ってしまうと、

• AWSアカウントのrootメールアドレス変更
• root含む全ユーザのログインパスワード変更
• 大事なシステムが稼働しているAWSアカウント解約
• マイニングなど、リソースの不正利用によるクラウド破産
• S3に保存した機密情報流出

などなど、とっても恐ろしいことが起こってしまいます。（※下2つはroot権限でなくとも起こりえます）

弊社にも、まれにrootユーザのアクセスキー漏洩事故、およびそれに伴うAWSアカウントの不正利用についてご相談をいただくことがあります。
rootユーザのアクセスキー流出による悲惨な事故の撲滅を祈って、このエントリを書いています…。
みんなでご安全なAWSライフを！！

どうすればいいの？

無いものは漏れようがないので、基本的にrootユーザのアクセスキーは存在しない状態が望ましいです。
もし今存在するのであれば、極力IAMユーザやIAMロールの利用に切り替えて、rootユーザのアクセスキーは無効化/削除していきましょう！

参考： rootアカウントでしかできない作業の一例
AWS操作をプログラム的に行う中では、root権限は必要無いことがほとんどかと思います。

rootユーザのアクセスキー有無の確認

rootユーザも含めたすべてのユーザのアクセスキーの有無、最終利用履歴、MFA設定等を一覧で確認できる認証情報レポートという機能があります。 （4時間に１回更新することができます）

AWS アカウントの認証情報レポートの取得 - AWS Identity and Access Management

アカウントのすべてのユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された認証情報レポートを生成し、ダウンロードできます。

以下のIAM権限があるユーザであれば、rootユーザでなくても確認可能です。

• iam:GenerateCredentialReport
• iam:GetCredentialReport

マネジメントコンソールでの確認方法

1. IAM管理画面右のメニューから「認証情報レポート」を選択します。

1. 「レポートをダウンロード」をクリックすると、CSVのダウンロードが始まります。

AWS CLIでの確認方法

以下の2コマンドでそれぞれレポートの作成、参照(CSV形式)ができます。

$ aws iam generate-credential-report
$ aws iam get-credential-report| jq -r .Content | base64 -D

データの見方

CSV中、user列が＜root_account＞ となっている行がrootユーザに関係する情報です。

以下の列どちらかあるいは両方がtrueになっている場合、
あなたのAWSアカウントにはrootユーザのアクセスキーが存在します！
（rootのアクセスキーは2つまで作れるため、1と2があります）

• access_key_1_active
• access_key_2_active

また、以下の列を確認することでそれぞれのアクセスキーの最終利用日、最近アクセスしたAWSサービス(EC2, S3, など)が確認できます。
ここがN/Aとなっていれば、IAMが情報追跡を開始した2015年4月22日以降はアクセスキーが一度も使われていないことがわかります。

• access_key_1_last_used_date
• access_key_1_last_used_service
• access_key_2_last_used_date
• access_key_2_last_used_service

レポートフォーマットの詳細は上記にもリンクを張っているこちらのドキュメントに記載があるため、ご興味あれば見てみてください！
（話は逸れますが、 mfa_active列がtrueになっているかどうかもセキュアな運用のため要チェックですね！）

アクセスキーの利用箇所を特定するため役に立つサービス

AWS CloudTrailでは、デフォルトで過去90日間のAPIコール履歴を記録しています。

まず、「全てのイベントを表示」から、直近90日間のイベントの表示を行います。

「ユーザー名」「root」でフィルターをかけて、rootの利用履歴を確認します。
各行の▼ボタンをクリックして詳細を見ると、アクセスキーの値、リージョン、発信元IPアドレスなどが確認できます。

アクセスキーの値を確認して、ASIAではなくAKIAから始まるものがあればそれが対象です。
「アクセスキーID」「AKIA...」で再度フィルターをかけましょう。

これらの情報を頼りにどのアクセスキーをいつ、何に利用しているかを特定しましょう！

※ 一部デフォルト設定では取得できないAPIや、CloudTrailによる記録に非対応のAPIもあるためご注意ください

rootユーザアクセスキーからIAMユーザアクセスキーへ

さて、rootアクセスキーを利用している箇所を特定したら、
アクセスキーをIAMユーザのものに置換していきましょう！
もしrootのアクセスキーを現在利用していないことが分かっている場合、この段落は飛ばして頂いて大丈夫です。

IAMユーザの作成

適切な権限を持つIAMユーザの作成

今後はrootユーザではなく、適切にポリシーを絞ったIAMユーザとそのアクセスキーを活用していきましょう。

ユーザとアクセスキーの作成方法については、次のAWS公式のページにまとまっていたのでご参照ください。

AWS アクセスキーの作成

1. IAM ユーザーを作成後、そのユーザーに対する最小限のアクセス許可を定義します。
2. その IAM ユーザーのアクセスキーを作成します。

もしも最小限のアクセス許可の特定がどうしても難しければ、最初はAdministratorAccess権限を付与するのでもrootより多少はマシになります。

けれども、付与する権限が広いほど流出時に被害が大きくなるリスクは高まっていきます。
できれば余分な権限は付与せず、少しずつ絞っていきましょう！

参考： ざっくりと設定したポリシーを出来るだけ絞り込んで適用し直したいときに | Developers.IO

プログラムやAWS CLI Configのアクセスキーを置換する

現在rootユーザのアクセスキーをプログラム内に埋め込んだりAWS CLIのConfigファイルで利用していた場合は
今作成したIAMユーザのアクセスキーに置換しましょう。

Pythonプログラムに埋め込んでいる場合の例

import boto3
from boto3.session import Session

session = Session(aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
                  aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
                  region_name='ap-northeast-1')
# 以下略

AWS CLI Configの例

# ~/.aws/config のケースもあります
$ cat ~/.aws/credentials
[hoge]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

キーの無効化 & 削除

これにてrootアクセスキーを利用しなくなりました！ではいよいよキーを消していきましょう。
そのまま削除ではなく、念の為、「無効化」→「削除」の2段階で作業することができます。
無効化状態からの復活は可能なので、まずは無効化してみて、しばらく待って影響がないことを確認してから削除ができるので安心ですね。

rootアカウントでログインして、「マイセキュリティ資格情報」を選択します。

「アクセスキー」のアクション欄から、無効化、あるいは削除を選択します。

お疲れさまです！！これにてrootユーザのアクセスキーの利用をやめることができました！！

IAM ベストプラクティスの話

以下のページにIAMのベストプラクティスがまとまっています。
今回ご紹介したrootユーザのアクセスキーの削除を始め、
IAMユーザ、IAMロール等の管理方法に関するAWSおすすめの方法が一覧となっています。

IAM のベストプラクティス - AWS Identity and Access Management

今回は切り替えの楽さを重視したためご紹介していないのですが、 実はベストプラクティスとしてはアクセスキーを利用した認証からIAMロールを利用いただく方法に切り替えていただくのがベストです。

Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する

IAMのアクセスキーを利用する場合、「何でもできる権限が漏洩する」というリスクは減らせるのですが、アクセスキーそのものがGitの公開リポジトリなどで漏洩してしまうリスクは依然として残ります。
IAMロールを利用すると、プログラムにアクセスキーを埋め込む必要がなくなるため漏洩が発生する可能性そのものも減ります。
rootアクセスキーの利用をやめたら、次はできるだけIAMロールの利用に切り替えていくことを検討していただけると幸いです！